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Abstract 

A research effort was undertaken to investigate how expert system technology could be applied 
to a satellite communications system. The focus of the expert system is the satellite ground 
stations. Diagnostic procedures associated with the ground stations are very demanding. 
Knowledge about the operational characteristics, communications strategies and the associated 
electronics of the ground station is required. 

A proof of concept expert system called GTEX (Ground Terminal Expert) was developed at The 
University of Akron in collaboration with NASA Lewis Research Center. The objective of 
GTEX is to aid in diagnosing data faults occurring with a digital ground terminal. Thou, 
research focused on large systems, this strategy can also be applied to the Very Small Aperture 
Terminal(V SAT) technology. An expert system which detects and diagnoses faults would 
enhance the performance of the VSAT by improving reliability and reducing maintenance time. 

GTEX is capable of detecting faults, isolating the cause and recommending appropriate actions. 
Isolation of faults is completed to board-level modules. A graphical user interface provides 
control and a medium where data can be requested and cryptic information logically displayed. 
Interaction with GTEX consists of user responses and input from data files. The use of data files 
provides a method of simulating dynamic interaction between the digital ground terminal and the 
expert system. GTEX as described is capable of both improving reliability and reducing the 
time required for necessary maintenance. 

GTEX was developed on a personal computer using the Automated Reasoning Tool for 
Information Management (ART-IM) developed by Inference Corporation. Developed for Phase 
II digital ground terminal, GTEX is a part of the Systems Integration Test and Evaluation(SITE) 
facility located at NASA Lewis Research Center. 
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1.0 Introduction 


System studies performed during the late 1970's indicated that advanced communications 
satellite technologies should be developed to utilize the Ka-band (30/20 GHz) spectrum. In 
order to demonstrate Ka-band satellite communications systems, NASA Lewis Research Center 
has conducted an advanced space communications program. This program will meet the needs 
of future NASA missions and will infuse advanced technologies into the commercial sector. 
One objective of the program is to apply advanced digital logic to space communications 
including the satellite ground terminal and network control. The program focuses on several 
major areas: advanced modulation and coding; space based processing and control; and ground 
based processing and control. The goal of ground based processing and control focus is to 
develop cost efficient terminals. Expert systems are being applied to diagnose ground terminal 
failures and provide autonomous operation. 


2.0 Background 

Extensive development of satellite communications is currently under way at the NASA Lewis 
Research Center. Using proof-of-concept subsystems and components, (IF switch matrices, 
solid-state amplifiers, traveling-wave tube, high-power amplifiers and low-noise receivers) a Ka- 
band satellite communications network simulation known as the Satellite Integration, Test and 
Evaluation (SITE) facility has been developed. This facility allows modulated data to be used to 
characterize the effect of microwave components on Bit Error Rate (BER) performance and 
SITE supports voice, data, and video through a Time Division Multiple Access (TDMA) burst 
terminal and a three ground terminal network. 

The ground terminal is a major element of the simulator and one of the more complex. Each 
ground terminal must be capable of acquiring satellite and network timing, maintaining 
synchronization to the network, and transmitting and receiving bursted data from other ground 
terminals in the network. 

Each ground terminal, shown in Figure 1, contains a 221.184-MHz system clock, transmission 
and reception timing and control circuits, compression or expansion first-in, first-out memories 
(FIFO) separate user clocks and their associated control circuits, an orderwire processor 
microcomputer, a user interface controller, and a 221.184-MHz serial minimum-shift 
key(SMSK) burst modulator/demodulator (modem) (Ivanic, et al. 1989). 

In the SITE ground terminal, users are simulated by a bit-error-rate test set consisting of a data 
generator (transmitting user) and a data checker (receiving user). A controlling computer creates 
realistic traffic patterns with users of varying data rates entering and leaving the system. The 
raido frequency (RF) components and links of the communication system can degrade the user's 
data which often results in bit errors. The users need to know the degree of data degradation to 
determine whether to tolerate it or compensate for it. Data degradation can be quantified by 
using a bit-error-rate (BER) figure. A BER provides a performance measure of the RF 
communication links, the RF and digital subsystems, and the overall satellite communication 
system. 
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Figure 1. - SITE Digital Ground Terminal Block Diagram 


Providing an interface to the users, the SITE ground terminals control the timing and the paths 
of the users' data transmission. Presently, each of the SITE ground terminals is capable of 
interfacing to three transmitting and three receiving users. The transmitting ground terminal 
multiplexes the data it receives from each transmitting user and bursts the data to the satellite at 
a high data rate. The receiving ground terminal receives the high-bursts and demultiplexes them 
so that each receiving user gets the proper data. (Shalkhauser 1988) 

Since the SITE digital ground terminal is itself a prototype, new errors frequently occur. This 
required the scope of GTEX to be very concentrated. The errors associated with the transmitting 
and receiving of user data is the primary focus of GTEX. 

Being developed as a diagnostic aid, GTEX will be used as a demonstrational prototype showing 
the feasibility of applying expert system technology in the area of high-rate digital 
communications at NASA Lewis Research Center. 


4.0 Development Environment 

GTEX is being developed using the Automated Reasoning Tool for Information Management 
(ART-IM) by Inference Corporation. ART-IM is a C-based toolkit for the development of rule- 
based, or knowledge-based, expert systems (ART-IM 1991). GTEX was developed on a low- 
cost development and deployment environment a personal computer(PC) running MS-DOS. 

ART-IM supports three methods of programming styles; procedural, ruled-based and object- 
oriented. The procedural language supported by ART-IM provides basic function calls, and 
allows simple interactions and conditionals to be performed. The rule-based structure uses the 
rule as the fundamental unit. Reacting to changes in the working memory, the rule can then fire 
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or execute based on the dynamic order of the changes which occur. Objects in ART-IM are 
represented by a schema. Control of an object is managed by sending a message to that object. 
An object reacts to a message by searching itself for an appropriate method and executing the 
actions associated with that method. 

The ART-IM procedural language can be extended using the 'C' programming language. User 
functions can be written in C and included with the ART-IM program which can be used like 
any other ART-IM function. Since functions defined in C are complied versus interpreted, the 
result is faster execution. This capability of ART-IM was fundamental in the development of 
the user- interface discussed in this paper. 


5.0 System Overview 



Figure 2. - GTEX Architecture 


The GTEX architecture is divided into the following subsystems: 

• Display subsystem 

• Control subsystem 

• Query subsystem 

• Knowledge base 
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A modular approach was beneficial in system development. An extended ART-IM function was 
constructed for communications between the knowledge base, display and query subsystems. 
This implementation allows communications to be established from both ART-IM and C. 

Syntax would be as follows: 

calling from ART-IM: 


(send-message system "message") 


calling from C: 

aofnSendMessage(a_art_symbol(sSystemType), a_art_string(sMessage)); 

Communications with the knowledge base are achieved by asserting a fact into working memory 
corresponding to the end-users action. Messages each subsystem handles will be described in 
detail in the designated subsection. 

The block diagram of the GTEX system architecture is shown in Figure 2. The diagram shows 
each subsystem and the possible communications paths. 


5.1 Display Subsystem 

A graphical environment was chosen to provide a dynamic interface. The GTEX interface shown 
in Figure 3 is capable of displaying dynamic system block diagrams, system status, and provide 
interactive dialog with the end-user. Dynamic system diagrams alert the end-user to changing 
conditions of the simulated digital ground terminal operation. Detailed diagrams of individual 
subsystems within the SITE ground terminal can also be displayed. Diagnostic messages 
regarding the inferencing process are conveyed to the end-user. Interactive dialog, implemented 
as a pop-up window, is provided to query information and provide a medium to display 
important messages. 

The display subsystem receives a message string from either the knowledge base or query 
subsystem. The message string is in the form: 

"Message-Type Message-Action" 

Table 1, enumerates the message string possibilities. 


Message Type 

Message Action | 

Display 

mmmsssmt 


Object | 

Initialize 

bhhhihi 

Warning 


Message 


Dialog 



Table 1 - Message strings for Display Subsystem 


107 







Figure 3 - GTEX Interface 


The interface to GTEX was developed in C using the Essential Graphics Library developed by 
South Mountain Software. The modularity of the system was preserved by only employing 'C' 
constructs in development. A pseudo object-oriented architecture was constructed to simplify 
development of required displays. 


5.2 Control Subsystem 

Since the diagnostic procedures are being performed in cooperation with a technician, control of 
GTEX is necessary. Basic actions such as starting the diagnostic process, resetting the system 
and selecting the type of system dialog are originated by the control system. 

Control of GTEX is performed by a function whose execution is controlled by ART-IM. The 
function, known as an asynchronous function, is called before the first rule-firing, between rule- 
firings and after the last rule-firing. 

Developed using the Essential Graphics library, the control system responds to mouse 
interaction. Once interaction has been detected, validation tests are performed and proper 
procedures taken. The final result is the assertion of the corresponding fact into working 
memory. Control is immediately returned to the knowledge base if no interaction has occurred. 
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5.3 Query Subsystem 

The end-user of GTEX has an option of two data input formats. A data file, simulating dynamic 
interaction with the SITE ground terminal is preferred. If data cannot be obtained from the data 
file, or at user request, GTEX will prompt the user for the required data. 

The simulated data file is a ASCII text file with the following record format: 

Object. Object-Property = Object-Value 

Initilialization of the simulator is controlled by a message received from the knowledge base. 

The message received contains the name of the ASCII data file. The ASCII file is parsed and 
the corresponding object and properties are created and values inserted. Since the simulator 
objects mimic the objects associated with the knowledge base, the ART-IM schema notation is 
used. 

To query a value, a message is received from the knowledge base denoting an object and the 
corresponding property of the value required. The inquiry begins by checking a status flag to 
decide if data is to be retrieved from the simulator. Found to be true, an object-property match 
is performed and corresponding data returned. Dialog is conducted with the end-user either 
when, a value is unavailable from the simulator or the status flag indicates that the end-user to be 
queried. During the dialog, the system halts execution until valid data has been obtained from 
the end-user. 


5.4 Knowledge Base 

GTEX performs the following tasks: 

• Fault Detection 

• Fault Isolation 

• Fault Recovery Recommendation 

The diagnostic procedure begins by determining the initial system configuration. Information is 
gathered about each data channel regarding the transmit, receive channels, and data rate. 

General information about the SITE ground terminal is also obtained. BER measurements are 
performed and evaluated on each of the user data channels to determine if tolerance limits have 
been exceeded. Once tolerance limits have been exceeded, the end-user is informed of the 
discrepancy and isolation of the fault begins. 

Three levels of isolation are performed. The initial stage of isolation determines which side, 
transmit or receive, of the user channel is causing the error. Isolation is then performed to 
determine which of the corresponding subsystems is in error. Finally the corresponding circuit 
board is isolated. Once the fault has been isolated and end-user informed, GTEX can be 
requested to recommend a fault recovery recommendation 


109 



6.0 Knowledge Base Architecture 

The knowledge base is divided into the following rule categories: 

• Display rules 

• Diagnostic rules 

• Demon rules 

Each rule category has its own salience or relative priority which is used in scheduling the rule 
for firing. This technique was implemented since the version of ART-IM used for development 
was unable to handle rule sets. Table 2 lists the salience values assigned to the individual 
categories. 


Rule category 

Salience 

Display Rules 

200 

Demon rules 

100 

Diagnostic rules 

0 


Table 2 - Table of Rule Salience 


6.1 Diagnostic Rules 

The diagnostic rules are the foundation of the knowledge base. These rules perform the 
fundamental steps required in diagnosing the digital ground terminal. They are responsible for 
asserting facts into the working memory, which results in the execution of the detailed 
procedures, implemented using "demon rules" discussed in this paper, for the current level of 
diagnostics. 

The diagnostic rules have the lowest priority of any rule group. This priority level is important 
in maintaining system integrity. The integrity is preserved by insuring that the diagnostic rules 
are reacting to current data. An example of a diagnostic rule is shown. 


(DEFRULE Determine-Channel-Configurations 

(SCHEMA Ground-Terminal-Configuration 
(Attenuators-Connected YESINO) 

(RF-Transponder-Connected NO)) 

=> 

(ASSERT (Determine Channel 1 Configuration)) 

(ASSERT (Determine Channel 2 Configuration)) 

(ASSERT (Determine Channel 3 Configuration))) 

This rule assumes that the ground terminal configuration was perviously determined. The 
connection of attenuators and the RF-transponder with the digital ground terminal is checked. If 
the attenuator connection is known and the RF transponder found not connected, then facts 
regarding the user data channel configuration are asserted in working memory. 
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6.2 Demon Rules 


Sitting dormant in the knowledge base are demon rules. The responsibility of the demon rules 
are to perform detailed diagnostic procedures. They are activated by the diagnostic rules which 
assert appropriate facts in working memory. The modification of objects is the primary 
procedure performed. 

An example of a demon rule is shown. 

(DEFRULE Determine-Channel-Configuration-Demon 
(DECLARE (SALIENCE ?*demon-salience*)) 

(SCHEMA ? Channel 

(INSTANCE-OF User-Channel) 

(Channel-Number ?Number)) 

?demon <- (Determine Channel ?Number Configuration) 

=> 

(MODIFY (SCHEMA ?Channel 
(Transmit-Channel 

=(SEND TX-Channel-Number User-Interface-Computer ?Number)) 
(Receive-Channel 

=(SEND RX-Channel-Number User-Interface-Computer ?Number)) 

(Data-Rate 

=(SEND Data-Rate User- Interface-Computer ?Number)))> 

(RETRACT ?demon» 

For each instance of a user channel in working memory, the rule fires which modifies the object 
after obtaining the data desired. The data in this case is the transmit and receive channels 
associated with this data channel and the corresponding data rate. Actual data values are 
obtained by sending a message to the appropriate object. 


6.3 Display Rules 

Display rules are responsible for setting and updating the display based on schema values in the 
knowledge base. They are also responsible for intercepting and processing fact messages from 
the control system. Rules regarding display have the highest priority to ensure that the display is 
always updated. An example of a display rule is shown below. 

(DEFRULE Select-User-Dialog 

(DECLARE (SALIENCE ?*display-salience*)) 

? display-fact <- (ACTION SELECT USER -DIALOG) 

=> 

(BIND ?*simulator* (send-message display-system "dialog simulator”)) 

(send-message display-system "message 102") 

(retract ?display-fact)) 

This rule shows a fact message from the control system which informs the knowledge base that 
the end-user wants to select the type of user-dialog. The right-hand side of the rule then sends 
two messages to the display system. 
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7.0 Summary 


As more emphasis is placed on developing low-cost efficient ground terminals, expert system 
technology will play an essential role. GTEX is being developed as a prototype, demonstrates 
the ability of expert systems to provide needed assistance in ground terminal operation. The 
modular approach taken will allow GTEX to adapt to new system designs. Adhering to this 
viewpoint, future consideration includes modifying GTEX to enhance the capabilities of the 
High-Burst Rate Link Evaluation Terminal (HBR-LET) designed for the Advanced 
Communications Technology Satellite (ACTS) Project at the NASA Lewis Research Center. 
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